-
Notifications
You must be signed in to change notification settings - Fork 7.8k
arch: arm: cortex_m: Consolidate SCB APIs and add backup/restore functions #93161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
arch: arm: cortex_m: Consolidate SCB APIs and add backup/restore functions #93161
Conversation
f56c70c
to
1df36d5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
may I ask where do you plan to use these new apis and if you plan to move all such apis from https://github.com/zephyrproject-rtos/zephyr/blob/34e47f4040c99d52fe0e5d5eb64b2904e14f8981/soc/nordic/nrf54h/pm_s2ram.c to arm folder?
I plan to use in either in soc specific implementation of suspend to RAM or move in the centralized suspend to RAM functions of Cortex M series. I do not plan to move all the API from such file to arm folder but actually taking inspiration and extract what could be general and not soc specific. I also added modification to |
5741c66
to
e657f97
Compare
508be9f
to
b70e73f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Otherwise LGTM.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, one more remark:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also request to have the .c and .h in the same commit (the 2nd commit with just .h doesn't make much sense to me)
Done |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Otherwise LGTM. -1 because Cortex-M3 has CPACR
Add two API to save SCB context and restore it, typically used in suspend to RAM use case. The scb_context_t and the backup/restore functions are designed to only handle SCB registers that are: - Mutable: Their values can be changed by software. - Configurable: They control system behavior or features. - Stateful: Their values represent a specific configuration that an application might want to preserve and restore. Register excluded from backup/restore are: 1. CPUID (CPUID Base Register) Motivation for Exclusion: This is a read-only identification register. 2. ICSR (Interrupt Control and State Register) Motivation for Exclusion (from restoration): While its current value can be read, directly restoring a saved ICSR value is highly dangerous and generally unsafe in an RTOS context. Contains Read-Only Status Bits: A significant portion of ICSR consists of read-only bits (VECTACTIVE, VECTPENDING, ISRPREEMPT, TSRUNPEND). These bits reflect the current state of the exception system (e.g., which exception is active, which are pending) and are managed dynamically by the CPU and the RTOS. Forcing a previous state onto these bits would corrupt the live system's interrupt handling. Contains Write-Only Set/Clear Bits: Some bits are write-only to set or clear a pending interrupt (PENDSVSET, PENDSVCLR, SYSTICKSET, SYSTICKCLR). If these bits were set in the saved context, restoring them might immediately trigger an interrupt or change its pending state unexpectedly, outside the RTOS's control. RTOS Management: In Zephyr (and other RTOSes), the kernel tightly manages the interrupt and exception state. Direct manipulation of ICSR's volatile bits could conflict with the RTOS's internal state machine, leading to crashes or unpredictable behavior. 3. CFSR (Configurable Fault Status Register) Motivation for Exclusion: This is a read-only status register that reports the current state of Memory Management, Bus Fault, and Usage Faults. It's used by fault handlers to determine the cause of a fault. 4. HFSR (HardFault Status Register) Motivation for Exclusion: Similar to CFSR, this is a read-only status register that reports the current state of HardFaults. It's for reporting, not for configuration or restoration. 5. DFSR (Debug Fault Status Register) Motivation for Exclusion: This is a read-only status register that reports debug-related faults. It's primarily used by debuggers and is not part of the application's runtime context to be saved/restored. 6. MMFAR (MemManage Fault Address Register) Motivation for Exclusion: This is a read-only register that stores the address that caused a Memory Management fault. It's a diagnostic register, not a configurable parameter. 7. BFAR (BusFault Address Register) Motivation for Exclusion: Similar to MMFAR, this is a read-only register that stores the address that caused a BusFault. It's a diagnostic register. 8. AFSR (Auxiliary Fault Status Register) Motivation for Exclusion: This register is implementation-defined and read-only. Signed-off-by: Michele Sardo <[email protected]>
|
This pull request aims to centralize and enhance the System Control Block (SCB) related APIs within the Arm Cortex-M architecture layer.
It adds of SCB Register Backup/Restore Functions by new utility functions (
scb_backup_registers
andscb_restore_registers
) for safe preservation and restoration of essential SCB register states. This functionality is crucial for advanced features such as suspend to RAM scenarios.See also #90001